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Abstract 


SAP security is still a dark world. Very little information can be 
found on the Net and almost every question related to security 
assessment of these applications keeps being unanswered. This 
paper has the intention to bring some light into that world, 
providing the results of a security analysis of the SAP RFC 
Interface Implementation. 


SAP RFC is the heart of communications between SAP systems, 
and between SAP and external software. Almost every system that 
wants to interact with SAP does so using the RFC interface. As 
stated by SAP: "The RFC library is the most commonly used and 
installed component of existing SAP software". 


In this paper we are going to describe discovered vulnerabilities in 
the RFC Library and their security impact. Furthermore, we have 
developed some attacks, exploiting default mis-configurations and 
design flaws in the Interface implementation, which will also be 
reviewed. We will also include workarounds and protections that 
will help SAP administrators prevent from the mentioned attacks. 


© 2007 Cybsec S.A. - All Rights Reserved 


CG EXPLOITING SAP INTERNALS: A Security Analysis of the RFC Interface Implementation. 


1. Introduction 


As many legacy and internally developed systems may be already installed (and successfully working) before 
SAP R/3 is implemented in an organization, SAP must provide a way to communicate with these partners. 
With that objective in mind, SAP has developed quite a lot of interfaces to communicate with other systems 
(HTTP, FTP, XML, ALE, EDI, ...). 

Among all these interfaces, there was one that demanded attention: SAP’s Remote Function Call (RFC) 
Interface. 


This interface is a central component of the SAP Application Server, and implements the most used protocol 
for communication between SAP systems and between SAP systems and external (non-SAP) systems. 


As it names implies, the objective of this interface is to allow systems to call function modules on remote SAP 
systems, and vice versa. 


The following section describes the basics of the RFC Interface. Experienced SAP administrators/security 
professionals can skip this section. 


2. Basics of SAP RFC Interface 


Originally, SAP implemented IBM’s CPI-C interface to communicate with other systems. This protocol enabled 
the direct transfer of data between systems and fitted well the basic requirements of data communication. 
However, complex applications demanded more that plain data transfer and the ability to call functions on 
remote systems was really tempting. Temptation became necessity and RFC was born. 


Extending CPI-C, RFC describes a client-server architecture where the server provides services as remotely 
accessible functions, in a very similar way to Sun’s RPC. 


We shall now differentiate between two type of RFC connections: Connections initiated in SAP Application 
Servers and connections initiated in external RFC systems. 


2.1. Connections From SAP Application Servers 


In SAP Application Servers (SAP AS from now on), RFC services are implemented as ABAP function modules. 
For a function module to be accessible by RFC, it must be defined as “Remote-enabled module” in its 
attributes configuration. 

These function modules receive parameters by the mean of PARAMETER structures (importing parameters) 
and also can receive (larger) data through TABLES structures. After processing, results are also sent in the 
form of parameters (exporting parameters) and/or tables. Besides, exceptions can be raised, which will 
propagate to the client. 


If an ABAP program in system PR1 wants to call a remote function module in system PR2, a RFC destination 
must be created in PR1. This destination is maintained through transaction SM59 and will be included in the 
function call specification. In concrete, the destination string is used as a index key for the RFCDES table. The 
associated table record has all the information needed to perform a connection with the target system. 
Following a function call in an ABAP program is presented: 


CALL FUNCTION ‘ZCUST_GETMONEY’ DESTINATION ‘PROD2’ 
EXPORTING 

ZCUST_ID = 100 

IMPORTING 
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MONEY = cust money 
TABLES 
DATA = cust_data 
EXCEPTIONS 

CUST NOT FOUND = 0 

TABLE EMPTY = 1 


In the case where a SAP AS wants to call a RFC function implemented in an external server, very little 
changes have to be done to the above ABAP function call: a new RFC destination has to be created, 
specifying the external server connection attributes, and modify the DESTINATION field of the CALL 
FUNCTION statement. 


2.2. Connections From External Systems 


External RFC systems are developed using the RFC Library. This is an API released by SAP to allow the 
creation of external software that interacts with SAP systems by the means of the RFC protocol. This library is 
available for every SAP supported platform. 


By using this API, it is possible to develop both external RFC clients and servers. Following we will provide an 
example of a basic external client. For more complex examples, you can view delivered examples within the 
RFCSDK. 


Following a simple RFC client program is presented: 


int main(int argc, rfc_char t **argv) { 


RFC HANDLE handle; 
RFC ERROR INFO EX rfc_error info; 

RFC PARAMETER importing[2], exporting[2], changing[2]; 
RFC TABLE tables[2]; 

RFC_RC rc; 

RFC_INT number=1; 


cfc char t *exception = NULL; 


/* Connect with SAP AS */ 


handle = RfcOpenEx ("ASHOST=127.0.0.1 TYPE=3 SYSNR=00 CLIENT=000 USER=SAP* PASSWD=pass", 
rfc error info); 
if (handle == RFC HANDLE NULL) { 


/* Connection error */ 
return 1; 


/* Definition of EXPORT parameters */ 


exporting[0].name = "EXP PARAMETER"; 

exporting[0].nlen = strlen(exporting[0].name) ; 

exporting[0].type = RFCTYPE INT; 

exporting[0].addr = &number; 

exporting[0].leng = sizeof (number); 

/* Next parameter must be NULL */ 

exporting[1].name = NULL; 

/* also unused structures */ 

tables[0].name = NULL; 

importing[0].name = NULL; 

changing[0].name = NULL; 

/* Perform the RFC Call and receive results */ 

re = RfcCallReceiveEx (handle, "HOME FUNCTION", exporting, importing, changing, tables, 
é&exception) ; 
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if (rc == RFC_EXCEPTION || rc == RFC SYS EXCEPTION || rc != RFC OK) { 
/* Process exceptions and errors. Grouped for the sake of space here.*/ 


} 


/* Process received parameters and tables */ 


/* Close the connection */ 
RfcClose (handle); 
return 0; 


2.3. External RFC Servers 
We may begin explaining that there are two types of External RFC servers: started and registered. 


A started external server is a program that is initiated by a Gateway Server when a RFC call matching its 
destination is received. If the server resides in a remote host, the Gateway connects with the remote host and 
starts the program. After the call is processed, the server program is closed. It is important to note that the 
most common way of connecting to remote hosts are through Remote Shell (rsh) or Remote Exec (rexec), 
basing authentication on trusting relationships. 


A registered external server takes a different approach: it registers itself at a specific SAP Gateway. In this 
registration process, the external server sends an ID string (Program ID) to the Gateway, under which the 
external server will be identified and reachable. Therefore, the destination in SM59 is configured to point to that 
Program ID. Upon a RFC call for that destination, the call is detoured to the external system associated to that 
Program ID. 


Following we present a simple registered external server program: 


static RFC RC SAP_API home function(RFC_ HANDLE handle); 


int main(int argc, rfc_char t **argv) { 
RFC HANDLE handle; 
RFC_RC rc; 


/* Register at SAP Gateway 


argv = "-aProgID -ggw_host -xgw_service" */ 
handle = RfcAccept (argv) ; 
if (handle == RFC_HANDLE NULL) { 


/* Couldn't register at SAP Gateway */ 
return 1; 


} 


/* Install available functions */ 
re = RfcInstallFunction("HOME FUNCTION", home function, "documentation") ; 


do { 
/* Wait for RFC Call and dispatch to one of installed functions */ 
rc = RfcDispatch (handle); 

} while (rc == RFC_OK); 


/* Close the connection */ 
RfcClose (handle); 
return 0; 


static RFC_RC SAP API home _function(RFC_ HANDLE handle) { 
RFC_RC rfc _ rc; 
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RFC PARAMETER parameter[2]; 
RFC TABLE tables[1]; 
RFC_INT number; 


/* Define reception parameter */ 
parameter[0].name "EXP PARAMETER"; 
parameter[0].nlen strlen (parameter [0] .name); 
parameter[0].type RFCTYPE INT; 
] 
] 


parameter[0].addr énumber; 
parameter[0].leng sizeof (number); 


parameter[1].name = NULL; 
tables[0].name = NULL; 


/* Get data from remote RFC client */ 
rfc_rc = RfcGetData (handle, parameter, tables); 


/* Process results */ 


return rfc rc; 


As you can see in the code, the server first registers at the Gateway Server. Next, it installs available functions 
through the Rfc/nstallFunction() function and finally a dispatching loop is initialized. Take note that there are 
many variations to these scheme. For more information check [1]. 


2.4. The Gateway Server 


You are probably wondering what the Gateway Server is. Let’s try to provide an explanation: Also known as 
CPIC-C Gateway, the Gateway is one of core SAP R/3 services. It allows SAP AS to interact with remote SAP 
and External systems. 

Logically, it provides three different services: the Gateway Reader (for TCP/IP communications) the Gateway 
Work Process (for LU 6.2 communications with IBM mainframes), and the Gateway Monitor (for 
administration). 


Security of the Gateway is provided by different means: 


The Gateway Monitor access is regulated through the profile parameter gw\monitor. This parameter allows 
administrators to specify if the Monitor access is forbidden (value = 0), enabled only locally (value = 1) or 
enabled both for local and remote access (value = 2). Up to SAP AS with kernel version 6.20, the last one is 
the default value. Later on this paper, we will see that remote access to this console gives attackers highly 
valuable information to perform advanced attacks. 


Security parameters related with interaction with started and registered external are managed through two 
files, secinfo [2] and reginfo [3]. The first one allow administrators to apply restrictions on started external 
programs. The last one specify parameters for restricting the registration of external registered servers. By 
default, these files does not exist which results in no restrictions being applied. 


2.5. Authentication and Authorization Mechanisms 

In External server systems, authentication and authorization tasks are responsibility of external software 
developers. Access control measures can be implemented by the use of the RfclnstallExternalLogonHandler() 
API function. If not explicitly installed, there are no authentication/authorization mechanisms and any received 


RFC call will be processed. 


When trying to perform a RFC call to a SAP AS from an External system, automatic authentication and 
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authorization take place, provided that the profile parameter auth/rfc_ authority check is set to 1 
(default value). For a user to be able to execute a function module, he must have a S_RFC authorization with 
the field RFC_NAME defined as the function module’s function group. 


By default, when a external RFC client performs a function call to a SAP AS, an automatic login check is done 


by the client's RFC Library, calling the function RFC_PING on the SAP AS first. It is possible to avoid this 
situation, by opening the connection with the “LCHECK=0” parameter in the connection string. 


2.6. Further Information 
It would be possible to keep describing SAP RFC for many more pages. It has different types (SRFC, tRFC, 


qRFC), features and configurations. If interested, you can find many more information in [4]. 


3. Security Analysis of the SAP RFC Interface Implementation 


Enough of that boring (but necessary) introduction. In this section we are presenting the results of the research 
carried out over the RFC Interface Implementation. Tests were done over SAP systems deployed in Microsoft 
Windows 2003 (Kernel version 7.00), communicating with external clients and servers developed with the 
RFCSDK for Windows and Linux, versions 6.40 and 7.00. 


3.1. Traffic Analysis 


The first (and obvious) thing you realize when starring at a network dump is that RFC communications are 
clear-text. You can quickly identify logon information, parameter and tables names and values, etc: 


01a0 00 00 00 00 00 00 06 05 14 00 10 5f 22 ea 45 5 ~es_..... eee _".E* 
01b0 22 c5 10 e1 00 00 00 cO a8 02 8b 05 14 01 30 00 TT availa a a evans 0. 
01c0 Oa 72 66 63 5f 73 65 72 76 65 72 01 30 01 11 00 .rfic_server.0... 
01d0 06 42 43 55 53 45 52 01 11 01 17 00 Ob 81 bb 89 » BCUSER.. «0 668 scen 
01e0 62 fc b5 3e 70 07 6e 79 01 17 01 14 00 03 30 30 b..?w.oy...... 00 
01f£0 30 01 14 01 15 00 01 45 01 15 05 01 00 01 01 05 rr Bieieiccar ge ann 
0200 01 05 02 00 00 05 02 00 Ob 00 03 36 34 30 00 Ob ~~)... ee eee 640.. 
0210 01 02 00 Oe 5a 43 55 53 54 5f 47 45 54 4d 4f 4e ....ZCUST_GETMON 
0220 45 59 01 02 05 14 00 10 5f 22 ea 45 5e 22 c5 10 EY...... EO cc 
0230 e1 00 00 00 cO a8 02 8b 05 14 02 01 00 09 43 40 ~~... ee ee eee eee cL 
0240 49 45 4e 54 5f 49 44 02 01 02 03 00 08 43 55 53 IENT_ID...... CUS 
0250 54 30 30 31 00 02 03 ff ff 00 00 ff ff 00 00 01 TOOL............ 


To prevent credential and information sniffing, SAP has developed SNC (Secure Network Communications). 
By default, SNC is not enabled. Of course, most organizations run with this configuration. 


To log into a SAP system, the classic credentials required are: client, username and password. You can clearly 
identify the first two pieces in the above dump, while there seems not to be a clue for the password. The 
reason is that the password is obfuscated. 


Analyzing different traffic dumps we discovered that the obfuscation algorithm turned out to be a simple XOR 
operation with a fixed key: 
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for each CHAR in CLEAR TEXT PASS 
OBFUSCATED PASS[i] = CHAR XOR KEY[i] 


where KEY = [0x96, Oxde, 0x51, Ox1e, 0x74, Oxe, 0x9, 0x9, 0x4, 0x1b, Oxd9, 0x46, Ox3c, 0x35, 0x4d, Ox8e, 
0x55, Oxc5, Oxe5, Oxd4, Oxb, Oxa0, Oxdd, Oxd6, Oxf5, 0x21, 0x32, Oxf, Oxe2, Oxcd, 0x68, Ox4f, Oxia, 0x50, 
Ox8f, 0x75, 0x54, 0x86, Ox3a, Oxbb] 


With this information, the process of obtaining valid credentials is just limited to the possibility of intercepting an 
RFC communication (without SNC). 

An additional point that is worth mentioning is that developer traces (files automatically created for debugging 
of connections) access should be secured, as they can have full traffic dumps from which valid credentials can 
be obtained. 


3.2 Vulnerabilities in the RFC Library 


As described in the previous section, if you want to develop an external RFC server, you would use the RFC 
Library to enable your server communicate with RFC client partners. 


As commented in [5], there are some RFC functions which are installed by default in every external RFC 
server. 

We have detected that many of these default functions can be abused to perform security sensitive operations 
over external RFC servers, with impact ranging from information disclosure to remote code execution. 
Following, we describe the analyzed functions and the security caveats detected: 


3.2.1. RFC_PING 


This function can be used to analyze availability of RFC Interfaces, both in SAP Application Servers and 
external systems. 


3.2.2. RFC_GET_DOCU 


Calling this function, an attacker can get information about installed (and callable) RFC functions in an external 
RFC server. 


3.2.3. RFC_SYSTEM_INFO 


This function, present in both SAP AS and external servers, returns quite a lot of information about the server's 
system. 


3.2.4. RFC_TRUSTED_SYSTEM_SECURITY * 


Developed for internal use by SAP only, this function can be abused to verify the existence of Windows users/ 
groups in an external server's system, its domains and trusted domains. 


3.2.5. RFC_SET_REG_SERVER_PROPERTY * 
This function enables the definition of properties of external registered servers. Calling this function with the 


appropriate parameters, allows an external client to get exclusivity in the use of the server. This clearly 
represents a Denial of Service vulnerability. 
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3.2.6. RFC_START_GUI * 


To allow the start of SAPGUI on Front-end systems, this function is also present in every external RFC server 
by default. Analysis of this function detected a buffer overflow vulnerability which, if properly exploited, would 
result in the ability to execute remote arbitrary commands over the external server’s system. 


3.2.7. SYSTEM_CREATE_INSTANCE * 

This function enables the creation of remote objects, where an object adapter is available. 

A buffer overflow vulnerability in the processing of received parameters was also detected in this function, with 
the same consequences as the above case. 


3.2.8. RFC_START_PROGRAM * 


The function with the irresistible name. This function enables the “controlled” remote execution of commands 
on external server’s systems. 

Analysis of this function revealed information disclosure and buffer overflow vulnerabilities, which would allow 
to execute remote arbitrary commands on the server 


To prevent from abuse, SAP delivered the RfcAllowStartProgram() function with the RFC Library. This function 
works as an ACL to regulate RFC_START_PROGRAM access: 


No RfcAllowStartProgram() = Remote execution disabled 

RfcAllowStartProgram("cmd1.exe") = Execution of "cmd1.exe" is authorized. 

RfcAllowStartProgram(NULL) = All commands are authorized. 
Further analysis of the RfcAllowStartProgram() function revealed that the process of validating the received 
command against allowed ones can be abused to execute (almost any) arbitrary commands over the server 
system: 


The function only verifies that the first N bytes of the requested command matches the allowed command, 
where N is the length of the allowed command. This allows you to send a request with the following format: 


“allowedCommand.exe\..\..\..\path\to\evil\command.exe” 


Of course, on caveat of this attack is that to perform it successfully, knowledge of an allowed command is 
needed. Again, this can be obtained through passive sniffing provided that SNC is not present. 


* Vulnerabilities discovered by the author and reported to SAP, who released appropriate patches. 
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3.3 Attacking SAP’s External Servers 


The RFC SDK is shipped with many examples. One of them is the rfcexec program. This program is 
delivered only for testing purposes, but is being commonly used in productive systems. rfcexec works as a 
external registered server and installs the following RFC functions: 


RFC_RAISE_ERROR 
RFC_MAIL 
RFC_REMOTE_PIPE 
RFC_REMOTE FILE 
RFC_REMOTE_EXEC 


Function names speak for themselves. This external server enables the execution of operating system 
commands, reading and writing files and sending mails. Clearly, it represents a huge security risk. 


Due to the fact that this service is deployed in many SAP installations, SAP started to release it with an 
external logon handler. Therefore, upon a RFC call for any of its functions, rfcexec first analyze the contents of 
the rfcexec.sec file. This file allows administrators to define restrictions based on different characteristics of 
the RFC client and the RFC request. Detailed information can be obtained at [6]. 


We have discovered that some of these validations are also flawed. To make the situation worse, the default 
configuration of this file is to allow everything. 


4. Advanced Attacks 


RFC Library vulnerabilities are simple that: vulnerabilities, whose life and joy end when the respective patch is 
installed. Beside discovering these vulnerabilities, we have developed some attacks that abuse default mis- 
configurations and what we think to be design flaws. Surely, these attacks will have a longer life than described 
vulnerabilities. 


To carry out these attacks, an attacker would need some information about the current deployment of SAP 
systems. Some of the possible ways of obtaining this information are passive sniffing (if SNC is not used) or 
having remote access to the Gateway Monitor. 


4.1. Evil Twin 


As we have previously described, an external RFC server working in Registration mode, registers itself at the 
Gateway specifying a Program ID. To allow the deployment of multithreaded external servers, it is possible to 
register a server program at the Gateway several times using the same Program ID. The problem is that any 
external server can register at the Gateway with an already used Program ID. 


You are know probably wondering how the Gateway reacts upon a RFC call to a Program ID belonging to two 
(or more) different servers. Our tests indicate that it implements a circular queue algorithm, dispatching every 
new connection to the next server of the queue. In the case that the selected server is busy processing another 
client’s request, the call is forwarded to the next available server. 

Therefore, this attack is quite simple (dishonoring the section title): 


1. Attacker opens connection to server with Program ID = EXT1, blocking the connections of other clients. 
2. Attacker registers an external server with Program ID = EXT1. 
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3. Eventually, the client tries to connect with the (original) external server, specifying EXT1 as the 
destination Program ID. 

4. As the server who registered first (the original) is busy with another connection, the call is forwarded to 
attacker’s controlled server. 


4.2. A Wiser (and Stealth) Evil Twin 


One problem with the above attack is that the normal flow of communication between the original client and 
server is interrupted. This situation may be undesirable and easily detected. Therefore, a wiser attack has to 
be made. The following idea came up: 


1. Attacker opens connection with Program ID = EXT 1, blocking the connections from other clients. 

2. Attacker registers an external server with Program ID = EXT1. 

3. Eventually, the client tries to connect with the (original) external server, specifying EXT1 as the 
destination Program ID. 

4. As the server who registered first (the original) is busy with another connection, the call is forwarder to 
attacker's controlled server. 

5. At this point the attacker is in control of client parameters and tables, being able to log or modify their 
contents. 

6. Attacker uses established connection with (original) external server, forwarding the RFC call. 

7. Attack receives (original) external server processing results. 

8. Send results back to original client. 

9. Disconnects from (original) external server. 

10. Back to step 1. 


The described steps are subject to change depending on the technique used to keep the original server 
unavailable to licit clients. If attacking a single-threaded external server, the described method will work fine. 
Otherwise, defining the exclusive use of the original server would be necessary, which will allow to avoid 
connecting/disconnecting from it in every loop of the attack. 


According to its methodology, this attack can be cataloged as a MITM attack over RFC. 


4.3. Attacking the SAP Application Server with a Registered Server 


This last attack changes the aim from external servers to the core of the system: the SAP Application Server. 
We will show how, the simple fact of being able to register an external RFC server may enable an attacker to 
completely control a SAP installation. 


There was one situation that was overlooked in the introduction to the SAP RFC Interface: apart from normal 
operation of client/server communication, it can happen that, after receiving a function call, a server needs to 
request more information from the client to complete the process. In this case, the server performs a callback. 


A callback works just as any other function call (using the same RFC Library functions), with a very slight 
difference: it uses the already established connection with its partner. The roles are temporary interchanged 
and a function call is sent to the client (now working as server). Both servers and clients are able to perform 
callbacks. 


If the client is a SAP Application Server, the callback hits the same context in the SAP system. In other words, 
the callback RFC call executes under the privileges of the user who initiated the first call, bypassing any 
authentication method. If the user has SAP_ALL authorizations (or any other privileged roles), you can 
completely control the SAP Application Server. 


The following steps describe the attack in detail: 
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Attacker opens connection with Program ID = EXT1, blocking the connections from other clients. 

Attacker registers an external server with Program ID = EXT1. 

Eventually, the client tries to connect with the (original) external server, specifying EXT1 as the 

destination Program ID. 

4. As the server who registered first (the original) is busy with another connection, the call is forwarder to 
attacker's controlled server. 

5. Attacker performs a callback over the established connection. Depending on initial user authorizations, 

privileged actions can be performed over the SAP AS. 


ON> 


5. Protection 


The described vulnerabilities in the RFC Library have been reported to SAP and patches are already available. 
Protection from the detailed attacks is also possible, mainly by restricting remote access to Gateway Monitor 
and effectively controlling the interaction with external servers through the reginfo and secinfo files. Finally, it is 
important to prevent credential and information sniffing. This can be done with proper network segmentation 
and activation of SNC. 


6. Conclusions 


Where installed, SAP R/3 probably represents the most critical system deployment of an Organization, 
integrating and processing all of it business-related information. This paper exposed different vulnerabilities 
and attacks that can be implemented against SAP’s RFC interface implementation, which is the default and 
most commonly used interface for communication between SAP systems and also with external systems. 
Protection for these attacks is possible and must be implemented. We still are researching on this subject and 
have already obtain some new interesting results, which will probably be included in a future publication. 
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